Network bandwidth management of media streaming applications, such as voice, video, music, instant messaging and other (near) real time applications is an evolving art.
Many devices on the network may share a link via a router with limited bandwidth, but the individual devices have no visibility on what is happening on the other devices. This link (which can be logically considered as a fixed bandwidth pipe connecting different parts of the network that acts as a bottleneck point.) and possibly other aspects of the underlying data network, can become “bottleneck points” which must be managed as a scarce, shared resource across many devices.
Managing network traffic can be effected where the devices on the network all originate from a single manufacturer and can therefore be configured to cooperate with each other. However, it is uncommon and rarely practical to have a network where all devices originate from a single vendor, and do not have the same capabilities.
Network bandwidth management can be effected by blind bandwidth reservation for various devices, but this can lead to unused bandwidth.
Attempts to manage network bandwidth in IP telephony applications can be based on predicting the path that the media will follow based solely on the destination telephone number. However, features such as call forwarding, forwarding to voice mail, call pickup, and line appearances on other phones imply that the original destination number and primary phone may not be represent the endpoint that will ultimately be connected in the call.
Accounting of bandwidth needs for only the primary destination path would therefore miss many likely cases (calls that should have been blocked may not be), whereas accounting for all possible paths would be quite pessimistic (calls that should have been allowed, including other calls in progress at the same time, may be unnecessarily blocked).
The current bandwidth management capabilities of Unified Communication Solutions are generally limited to the counting of calls of routes programmed between two or more systems in an IP network. The aggregate bandwidth usage across multiple routes is not controlled nor is the bandwidth consumed to remote IP phone users accounted for. A known alternative is for the call controllers or the endpoints themselves to interact directly with the network infrastructure, for example extracting current bandwidth utilized from IP routers on the predicted media path. Since there are few well agreed standards-based interfaces to extract such information, and there is large variance between vendors, such an approach necessarily creates a number of undesirable assumptions and deployment constraints, making a practical multi-vendor solution difficult. Since multiple network elements may need to be queried for any particular flow, there would also be considerable messaging traffic at call setup time to be able to make any determination. Also, since network infrastructure does not generally have knowledge of the meaning of the traffic it carries, it is not possible to determine bandwidth used for any particular application and thus use this information to manage that application's usage.
Another known alternative is for the end devices to negotiate bandwidth resources directly with the network infrastructure, for example using Resource Reservation Protocol (RSVP), (as described in Braden et al., Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification Network Working Group, IETF Request for Comments 2205, http://www.ieff.org/rfc/rfc2205.txt)). However these techniques add considerable complexity to deployment, and require RSVP-aware network elements be in place across all parts of the network where call media would potentially flow. The latter assumption adds large costs, and is not feasible in the general case of arbitrary pairs of endpoints involved in the flows (which is fundamental to VoIP applications.
It is desirable to obviate or mitigate at least one of the above-described disadvantages, and in any event to provide a novel network traffic management infrastructure.